this was a failed attempt because we realized we cannot work with preinitialized images and optimal layout in host visible memory, correct?

let's remove the body of the function and replace it with comment, save some LoC and add some documentation here on why we failed.

• try 2D workgroups.
• make workgroup size 128x4 (make sure it reflects on you dispatch) --> 128*4=512 is a good workgroup size, it can fit exactly 3 workgroups on modern SMs
• pixelPos will be just the global thread idx. we need to have individual offsets for each tile requests
• your tile size is PoT, you could just use bitshift with 7 for division << TILE_SIZE_LOG2. for modulo use &127u or &(TILE_SIZE-1)
• tileIdx will globalPos.xy << 7 (define TILE_SIZE_LOG2)
• localPos will be globalPos.xy&127
• your start read location will be tileIdxTILE_SIZETILE_SIZE or tileIdx << 14u
• you get it :D I won't continue

• make the workgroup 2d 16x16 or a 512 1D workgroup
• but it needs to handle 16x16 region of the tile
• your read pos stays the same with flattened global idx (we need to make sure you're reading contigously)
• morton::code<false, 7, 2> mc; you now only need 4 bits for 16x16 so it becomes 4,2 I think
• use the bitshift and & for division and modulo like my prev commit.
  • it's very likely the compiler already does this optimization for you since TILE_SIZE is a macro, but it's good practice, in case it changed later to a push constant or something not known at compile time
• make sure this change is reflected on your dispatch;
  • since each tile is 128x128, it'll take 64 workgroups of size 512 to handle copy of a single tile for you
  • use morton code locally within this 16x16 to figure out the write location + add offset.
  • doing morton on 16x16 tiles with added offset is no different than doing morton globally on a 128x128 tile (see image below)

Mortong Example for 16x16 group:
thread 0: reads(0,0) at location 0 writes to pixelPos(0,0)
thread 1: reads(1,0) at location 1*ByteSize writes to pixelPos(1,0)
thread 2: reads(0,1) at location 2*ByteSize writes to pixelPos(0,1)
thread 3: reads(1,1) at location 3*ByteSize writes to pixelPos(1,1)
thread 4: reads(2,0) at location 4*ByteSize writes to pixelPos(2,0)
...
make sure this is what happes, reads are contigous, writes are morton ordered
might be actually easier to achieve this with single 1D 512 workgroup, not sure

btw we're not going to go with morton benchmarking any further, but let's just fix it up and make it work as we first intended.

add: "The devices we tested on didn't allow creating OPTIMAL images over host visible memory"

you could use uint32_t2
it's in nbl::hlsl namespace. makes your life easier with 2D/3D params

remove the unused load function. I don't think they are used anymore, right?

confusing semantics, you're using ID for GroupThreadID here, but above in SnakeStore you're using the same name for global disaptch ID